eDirectory Background Processes Notes

Describe eDirectory Background Processes

Changes are recorded in the change cache. The change cache assumes that there is more than one replica, so it stores a list of objects that need to be synchronized or purged so that the information can be communicated to other replicas.

The partition root object receives a replica ring (or replica list) at creation. When changes are made to objects within a partition, those changes are sent to all other replicas of that partition using the replica list of the partition root object.

Servers can synchronize out to multiple servers simultaneously, but the receiving servers can only receive 1 synchronization at a time. Every replica must be contacted.

Synchronization is generally schedule to execute 2 minutes after the database successfully initializes, then rescheduled upon completion to execute again in 60 minutes (the heatbeat). The heartbeat allows each server in a replica ring to periodically make sure it is still “alive” and synchronized, and occurs even if no changes have been made recently.

Synchronization interval ranges from 5 seconds to 60 minutes depening on the type of information updated.

For synchronization to be successful, the partition root object stores several important attributes:

Transitive Vector
A cache table of what the servers know about each other:

1. Each server’s distinguished name (or entry ID for the local server)
2. Last modification time stamp received for each replica
3. Number of replicas in the ring
4. Replica number for each replica in the ring

When a replica is modified on a server, that server updates the modification time stamp for that replica in its local transitive vector. It then checks its local transitive vector for each server in the replica ring.

Any server with a transitive vector holding a time stamp older than the local time stamp causes the server to initiate the synchronization process.

Whenever servers communicate with another server in the replica ring, they keep a record of the other servers’ transitive vector. This allows the servers to know what information needs to be sent to each replica to keep all the replicas synchronized.

Last Successful Sync
Lists amount of time since all replicas of a partition were able to successfully synchronize from this server (i.e. All Processed=Yes).

Maximum Ring Delta
Lists amount of data (in time) that may not be successfully synchronized to replicas in the ring. Shows you how far out of sync replicas are. Any maximum ring delta less than 60 minutes (the default Outbound Sync interval) shows a normal state, otherwise there is a problem.

Replica’s Perishable Data Delta
Lists how much data (in time) would be lost if the replica were lost.

Describe and Analyze the Limber Process

The limber process maintains tree connectivity by keeping server-specific information up to date.  It is used to do the following:

1. Verify the Tree Name
2. Verify the Server’s Network Address and Version Attributes
3. Find the Root-Most Entry
4. Start Predicate Statistics
5. Change the Network Address

Verify the Tree Name
When a server receives a request to check the tree name from another server in the tree, or if a server needs to establish communications with another server in the tree, the limber process starts.

Verify the Server’s Network Address and Version Attributes
It first makes a list of server addresses to determine if the server is in the right tree. The list includes servers holding replicas of the partition that holds the server object.

If it was prompted by a request to check the tree name, the operation inserts the server identified in the request at the head of the list.

Find the Root-Most Entry
It then sends a ping request to each server in the list, in order and selects the responding server whose root-most entry is closest to the tree root.
If the selected server has the same tree name as the current server, the process halts.

Tree name checks occur for 2 reasons:

1. The tree name has changed at the server holding the master replica of the root partition and that server sends the request to all servers in the tree. If the request fails to reach a server, the name will eventually be changed anyway.
2. Whenever a server connects to another server for server-to-server exchanges, it uses the NDSPing operation to test the validity of the other server. If it finds the other server has a different tree name than itself, it sends a request to check the tree name to that server and does not use the connection for server-to-server exchanges.

Authentication between servers is initiated through background authentication procedures, if it succeeds, the limber process assumes that the server must be in the same directory tree.

The requesting server then changes its tree name to the one reported by the selected server.

Start Predicate Statistics
This is a server-specific history of the objects most often searched for by users, managed through the ndsPredicateStats object, created at the time of the eDirectory installation. The object is the server name with –PS appended.

Predicate Data can be used to identify a need for indexes to improve the speed if future information access. It is not intended to be run all the time because collecting the stats affects search performance and can create large databases.

Use predicate stats if you suspect performance issues are related to a particular directory lookup.

Change the Network Address
Don’t change server names and IP addresses at the same time, in order to allow for an anchor by which the changes can be updated by the limber process. Only make the change to one server at a time, then reboot and ensure the other servers can see the change before continuing with other changes.

Determine when the Process Runs

The limber process occurs when:

1. Five minutes have elapsed since the eDIrectory database opened (server reboot) and every 180 minutes thereafter
2. A network address is changed (on Windows or NetWare)
3. A network administrator forces the process to run

Force the Process to Run
Rather than wait for the process to run, you can force it to run immediately via Agent Configuration/Agent Triggers in iMonitor or at the server prompt:

SET DSTRACE=ON
SET DSTRACE=+LIMBER
SET DSTRACE=*L

Describe and Analyze the Schema Synchronization Process

Schema synchronization is a separate process from the Novell eDirectory synchronization of objects. One can succeed whilst the other fails.

Schema synchronization does not use a replica ring to determine which servers to send the schema updates to. Schema updates are sent to the servers that contain replicas of a given partition and child partitions of the given partition.

All schema changes are required to take place at the [Root] partition, so the modifications will flow down and all servers will receive updates.

Replica depth shows which servers are stored on the server, a replica depth of 0 means a server holds a copy of the [Root] partition. A replica depth of 1 is the child partition of the [Root] replica.

A replica depth of -1 indicates that the server does not hold any replicas.

The SchemaSyncList lists the servers that a server synchronizes schema updates to. This is created by reading the replica depth. The servers at the same depth or below will receive any schema updates.

Determine when the Process Runs
The process is schedule to run 1000 seconds after successful database initialization and then reschedule to run again 240 minutes after the schema synchronization is complete (by default).

Force the Process to Run
Rather than wait for the process to run, you can force it to run immediately via Agent Configuration/Agent Triggers in iMonitor or at the server prompt:

SET DSTRACE=ON
SET DSTRACE=+SCHEMA
SET DSTRACE=*SSD
SET DSTRACE=*SSA

Describe and Analyze the External Reference Check Process

This process maintains object attributes that keep track of external references to objects.

The external reference attribute has 2 parts:

1. Distinguished names of servers holding the external reference (remote server name)
2. Entry ID of remote server (remote ID)

The external reference check process does the following:

1. Verifies whether the original entry still exists and if the reason for its existence is still valid
2. Makes it possible for all references to an entry to be deleted
3. Facilitates the renaming and moving of entries
4. Sends a link request to a server holding a writable entry. This server checks the entry creation time against the creation time of the actual entry to verify that the request is operating on the correct entry. This request causes the external reference to be deleted.

The process makes it easy to maintain the external references by periodically verifying the remote server name and remote ID of each external reference attribute of entries.

Determine when the Process Runs
The external reference check process runs by default every 13 hours (780 minutes). This interval can be changed through iMonitor under Agent Configuration/Background Process Settings (Backlink/DRL Interval) and also via the following at the server console prompt:

SET DSTRACE=!Bminutes

Force the Process to Run
Rather than wait for the process to run, you can force it to run immediately via Agent Configuration/Agent Triggers  (Reference Check) in iMonitor or at the server prompt:

SET DSTRACE=ON
SET DSTRACE=+BLINK (or +B)
SET DSTRACE=*B
SET DSTRACE=*SSA

Describe and Analyze the Obituary Process

Are used by eDirectory to retain outdated information for objects until the updated information has been replicated throughout the network. Examples include entries that have died or been moved, renamed, deleted, or restored but have not been synchronized yet.

Obituaries are used to avoid name collisions during certain operations. They provide a unique identification, other than the object name, that may be required in order to resolve certain functions.

Although sometimes thought of as a separate process, the janitor, purger, and replica synchronization processes all play a part in processing obituaries.

eDirectory uses the obituary attribute to flag instances of objects across multiple servers. By doing this, no further changes can be made until the delete, move, or rename change has been propagated to all servers holding a replica of the object’s partition.

When flagged for deletion, an object goes through the following stages before being removed from the tree:

Once marked Flag=0004, it is up to the local server’s local database to purge the obituary.

Determine when the Process Runs
Since obituaries are attribute values, eDirectory synchronizes them the same way as other attribute values in the replicas.

Force the Process to Run
Rather than wait for the process to run, you can force it to run immediately via Agent Configuration/Agent Triggers  (Janitor) in iMonitor or at the server prompt:

SET DSTRACE=*J
SET DSTRACE=*F
SET DSTRACE=*SSA

You can use DSREPAIR to check External References, launch it with the –A parameter and select Advanced Options/Check External References. DSREPAIR will display a list of external references and obituaries that have not been purged on the server.

The following table shows obituary types and the associated operation and number:

Describe and Analyze the Janitor Process

The Janitor process cleans up after a replica synchronization cycle has completed successfully. As the Janitor scans the partition, it:

1. Determines whether the partition’s root entry has been renamed. If it has, the Janitor notifies all external references of the root entry of the new name
2. Calls the purger, which purges deleted entries and values that have been synchronized with all replicas
3. Purges Move expectations that are more than 10 minutes old

Janitor then uses the 2 lists generated in scanning the partitions to synchronize the external references. For each entry in the Release ID List, the Janitor sends a Release Moved Entry request to the destination entry. If successful, the obituary can then be purged. For each entry in the Notify External Reference list, the Janitor requests external reference synchronization and specifies the operation that must be performed on the external reference.

Determine when the Process Runs
By default, the Janitor process runs every 2 minutes.

Force the Process to Run
Rather than wait for the process to run, you can force it to run immediately via Agent Configuration/Agent Triggers (Janitor) in iMonitor or at the server prompt:

SET DSTRACE=ON
SET DSTRACE=+J (or +Janitor)
SET DSTRACE=*F

Describe and Analyze the Purger Process

The primary purposes of the eDirectory replica purger process (purger) are to clean up:

1. Entries that have been through the obituary process
2. Values that couldn’t be deleted earlier, such as a user object being deleted from a group at the same time as it is being used by someone else

The purger marks deleted records as unavailable that have been synchronized with all replicas.

Determine when the Process Runs
The purger process is scheduled to run by other eDirectory replica synchronization background process.

Force the Process to Run
Rather than wait for the process to run, you can force it to run immediately via Agent Configuration/Agent Triggers (Purger) in iMonitor or at the server prompt:

SET DSTRACE=ON
SET DSTRACE=+J (or +Janitor)
SET DSTRACE=*J or SET DSTRACE=*F